Cream of the Crop 21/Cream of the Crop 21 (Terry Blount) (October 1996).iso/utility/time868e.zip/TIME868.HLP

OS/2 Help File | 1996-09-17 | 27KB | 709 lines

ΓòÉΓòÉΓòÉ 1. Help for TIME868 Version 5 ΓòÉΓòÉΓòÉ

Use TIME868 to set your system clock using the Time Protocol. This protocol is
accurate to plus or minus one second. A variety of features support several
modes of operation for both permanent and dial-up access to time servers.

TIME868 also operates as a Time Server for redistribution of accurate time to
local clients.

TIME868 provides a graph of the adjustments made for visual reference.

Related Information:

     Choosing a time server
     Setting up the program
     TZenvironment variable
     Dialog fields
     Providing a time server
     USNO time server
     National Institute of Standards and Technology
     About the Time Protocol
     Registering
     Changes in Version 2 (b)
     Changes in Version 3 (c)
     Changes in Version 4 (c)
     Changes in Version 5 (c)

 Copyright 1995,1996 Norbert Dey


ΓòÉΓòÉΓòÉ 2. Choosing a time server ΓòÉΓòÉΓòÉ

The basic reason for synchronizing your computer's clock is so that your value
for a particular increment of time is the same or very close to the value used
by your colleagues.

You have two basic choices: everyone can synchronize to the same clock or
everyone can synchronize to one of several standard clocks.

If you have no need for the exact standard value for the time, everyone simply
can synchronize to a conveniently available clock. In many applications, only a
comparison of times is necessary ... this file was created after that file ...
and so forth. As long as the clock is accurate to ordinary human standards (a
minute or so), this is sufficient.

If it is impractical for all of your colleagues to synchronize to the same
clock, you will need to find a server which itself is traceable to a precise
standard clock.

Some Internet service providers and larger institutions will provide time
service which is synchronized to a standard time source. If you have a local
source of accurate time, it is your best choice for a time server.

All of the servers listed by this program are Stratum 2 or better in NTP terms.
This means that they are normally very good clocks. (Sometimes they may have
problems and drift off. A suspicious time should be checked against another
server.)

Not all of the servers listed provide service on both TCP and UDP protocols. If
one protocol does not work, try the other. If both are provided, UDP will
generally give the best results.

Another factor in the choice is the distance to the server in network time. A
server with a long delay will give poorer results than a server with a short
delay. Long delays are perhaps due to network congestion over that route and
therefore will be quite variable. Since the time value returned by the server
is the time at which the packet left the server, its accuracy depends on a
quick trip to your system.

The network latency is reported in the log. This is calculated as 1/2 of the
total round trip on the assumption that the delay is symmetrical. The latency
is taken into account when computing the variance.

A useful comparison is the difference between the latency of the selected
server and your Internet provider or gateway. I typically get 74ms latencies to
my service provider over a 28.8 modem.

If you are operating through a firewall, your firewall system itself may be the
only outside time source, even if you have limited access to other services.


ΓòÉΓòÉΓòÉ 3. Help for TZ Variable ΓòÉΓòÉΓòÉ

The TZ variable is set by a line in the config.sys file. This information
corresponds to the IBM definition for the TZ variable in OS/2.

If you are in the continental USA, use one of these:

     set TZ=PST8PDT
     set TZ=MST7MDT
     set TZ=CST6CDT
     set TZ=EST5EDT
     set TZ=AST4ADT

 Some other countries for examples:

     Israel: set TZ=IST-2IDT,4,3,6,3600,10,1,6,7200,3600
     Italy: set TZ=CET-1CDT,3,-1,0,7200,10,-1,0,10800,3600
     Newfoundland: set TZ=NST3:30NDT
     New Zealand: set TZ=NZS12NZD,9,4,0,3600,3,4,0,7600,3600
     Peru: set TZ=EST5EST,1,0,0,3600,2,0,0,3600,0
     Singapore: set TZ=SST-8SST,1,1,1,0,1,1,1,0,0

 Some countries and parts of the USA do not change time during the summer. For
 these, use the following form:

 set TZ=AAAOAAA,1,1,1,0,1,1,1,0,0

 where AAA is the name of the time zone (MST for Mountain Standard Time, CST
 for Central Standard Time, SST for Singapore Standard Time) and O is the
 offset from UTC/GMT.

 Otherwise you can construct your own TZ variable from the following
 information. The string is composed of 10 parameters, separated by commas. The
 first parameter is SSSnDDD where SSS is a 3-character label for standard
 (winter) time. This is usually all letters, but can contain digits and blanks
 after the first character. DDD is a corresponding label for daylight savings
 time (summer time).

 The n between the SSS and DDD is the number of hours UTC is different from
 your local time (UTC - local time). Use +n or -n as appropriate.

 If your local time zone is not an even number of hours from UTC, you may use
 the form [+/-]hh:mm:ss. For example, PST+8:00:00PDT. Warning, this extended
 form was first introduced in CSD10 for the IBM C compiler in August 1994 (see
 APAR PJ14456). Other programs linked before CSD10 may not recognize this form.

 The remaining parameters deal with the dates and times when the change is made
 to summer time and back to winter time. If your time changes follow the USA
 rules, then you do not need to supply the remainder of the parameters.
 Otherwise you need to supply them all. If only a portion of the additional
 parameters are supplied, the whole set will be ignored and they will appear to
 be totally ineffective.

 Parameters 2-5 describe the start of summer time.

 Parameter 2 The starting month of summer time (1-12).

 Parameter 3 The starting week of summer time according to the following list:

     1 - the first week of the month
     2 - the second week of the month
     3 - the third week of the month
     4 - the fourth week of the month
     0 - the change occurs on a specific day of the month
     -1 - the last week of the month
     -2 - the next to last week of the month
     -3 - the second to last week of the month
     -4 - the third to last week of the month

 Parameter 4 The starting day of summer time. The day of the month (1-31) if
 parameter 3 was 0, otherwise the day of the week (0-6).

 Parameter 5 The starting time-of-day (local time) in seconds. (3600 seconds is
 1AM.)

 Parameters 6-9 describe the end of summer time.

 Parameter 6 The starting month of winter time.

 Parameter 7 The starting week of winter time (coded like parameter 3.)

 Parameter 8 The starting day of winter time. The day of the month (1-31) if
 parameter 7 was 0, otherwise the day of the week (0-6).

 Parameter 9 The starting time-of-day (local summer time) in seconds. (7200
 seconds is 2AM.)

 Parameter 10 The final parameter specifies the amount of time shift in seconds
 (3600 = 1 hour.)

 For example, I could use:

           set TZ=PST+8PDT,4,1,0,3600,10,-1,0,7200,3600

 In ordinary language, this reads as: Winter time is called 'PST' and summer
 time is called 'PDT'. I am 8 hours West of the zero meridian. Summer time
 starts on the first Sunday of April at 0100 local time. Summer time ends on
 the last Sunday of October at 0200 local time. When summer time is in effect,
 one hour (3600 seconds) is added to local time.

 Note:EMX-based programs have a different format for the TZ variable. If you
 use EMX programs, you can set that variable with the name EMXTZ. If the
 variable EMXTZ is available, the EMX programs will use it in preference to the
 TZ variable.


ΓòÉΓòÉΓòÉ 4. Help for dialog fields ΓòÉΓòÉΓòÉ

The following panels describe the dialog fields.

 Site      selection
 Hostname  of reference server
 IP        address of server